The World Wide Web offers to users the opportunity to access millions of documents which are on thousands of Web content servers. Access to these documents is performed by a Web browser operating on a client device. The Web browser provides the user with a simple look and feel. Behind this simple user view, a large infrastructure is deployed to allow access to any document resident on a Web content server. The response to a request issued by a user may take a long time, particularly when the Web content server is located far away from the requester site, is connected through a network link with low performance, or is heavily loaded. The requested document has to be transferred through the network at each request, thus requiring high network performance, especially if the objects have a very large size.
One way to minimize the response time and to decrease the network loading is to have a Proxy cache server located near the user. The role of a Proxy cache server is to intercept a request for information from a Web content server and to verify if the requested document or object is locally available and, if this is the case, to use this local copy instead of the original that is stored on the Web content server.
Typically, the most common Proxy servers cache a particular page only after a user requests it. However, specified URLs (pages or more generally Web objects) may be pre-fetched in the cache before they are effectively requested by a user as follows:                Load specific URLs defined by the administrator.        Load the most popular URLs from the previous day's activity.        The refresh process can also follow a specified level of HTML links to objects in the document and caches all the linked objects (delving method).        
The standardized protocol supporting the flow between a client and server transferring hypertext or hypermedia Web information is the Hyper Text Transport Protocol (HTTP). In an HTTP command to request information from a client browser to the Proxy cache server or from the Proxy cache server to the Web content server, only one object can be obtained at a time.
Even if they have been already stored in the memory of the Proxy cache server, the objects need to be regularly refreshed because they are updated in the Web content servers and are no longer valid in the Proxy cache server. The refresh operation is performed either ‘on the fly’ upon a request of a client device browser or during refresh operations periodically started, most of time during the night, by the Proxy cache server.
One problem with the operation of refreshing Proxy cache servers from Web content servers is the amount of information to be downloaded.
A first solution exists to reduce the amount of information downloaded from the Web content servers to refresh the Proxy cache server. The Proxy cache server first stores, for each object, an expiration date which is considered as the limit date of validity of an object. Some objects such as stock values are never cached. If this object is relevant to the news, the expiration date is the same day because this information is updated in the Web content servers more than once a day. If the object is a recipe it can be kept a few months without being considered as invalid. Another type of information stored for each object in the Proxy cache server is the ‘last modified’ date: this is a date sent by the Web content server attached with the object indicating the last time the object has been updated in the Web content server. When information requested by a client device browser is found in the memory of the Proxy cache server with an exhausted expiration date, the Proxy cache server issues a special request known as “if -modified-since.” The Proxy cache server sends a ‘last modified’ date along with the object to be refreshed. The Web content server compares the ‘last modified’ date of the object with the date attached to the version of the object currently stored in the Web content server. The Web content server sends back the object to the Proxy cache server only if the object has been modified since it was last received by the Proxy cache. This solution is currently used by products implementing the RFCs describing the HTTP/1.1 protocol, for instance, currently, the RFC 2616. One software product implementing this refresh method is the IBM Web Traffic Express for Multiplatforms.
The solution of the prior art reduces efficiently the amount of information downloaded by a Web content server to the Proxy cache server during a cache refresh operation because only the objects which have been updated on the Web content servers are sent to the Proxy cache server. However, this solution generates one couple of request/responses under HTTP protocol, for instance, for each object to be refreshed in the cache. This has an impact on the traffic load through the network. A second impact is that the modification of an object on the Web content server is detected by the date of last update. This date indicates when the document has been last saved on the Web content server, but does not give any insurance about the content modification. Consequently, refresh operations may be performed on objects which have been replaced on the Web content server but have not been really modified since the last date of refresh. In consequence, objects could be uselessly sent to the Proxy cache server. Saving useless object refresh operations is particularly relevant when more than one object is refreshed at a time and when the size of objects is large.